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SUMMARY 


This  is  an  interim  report  reviewing  the  implementation  and 
acceptance  testing  of  the  seismic  Communication  and  Control  Processor 
(CCP)  installed  at  the  Seismic  Data  Analysis  Center  (SDAC). 

The  Communication  and  Control  Processor  (CCP)  is  the  central 
node  in  the  communication  system  for  the  VELA  Network.  The  CCP 
receives  data  from  the  on-line  seismic  stations,  reformats  and 
regroups  the  data,  and  transmits  the  data  to  the  archival  store, 
the  SDAC  processing  center,  and  other  destinations  as  required. 

The  CCP  also  maintains  information  on  the  status  of  the  VELA 
network  and  performs  some  quality  control  and  signal  processing 
operations . 


The  CCP  is  a 4 processor  system  using  the  PLURIBUS  multi- 
processor architecture.  It  was  installed  at  SDAC  in  July  1975 
and  acceptance  testing  was  completed  in  February  197 6. 
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INTRODUCTION 

As  part  of  the  effort  under  the  VELA  program  for  improving 
the  capability  to  detect  and  identify  underground  nuclear  explosions 
by  seismic  means,  ARPA  is  supporting  the  development  of  a world- 
wide network  of  seismic  stations.  Some  of  these  stations  will 
communicate  on-line  with  the  processing  center  at  the  Seismic 
Data  Analysis  Center  (SDAC)  and  v^lth  a large  archival  storage 
system  at  Computer  Corporation  of  America  (CCA).  The  system 
design  makes  use  of  both  leased  lines  and  the  ARPA  Network  for 
communications  in  this  seismic  network. 
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SYSTEM  IMPLEMENTATION 


The  CCP  was  implemented  using  the  BBN  designed  PLURIBUS 
multiprocessor  system  based  on  the  Lockheed  Electronics  SUE 
minicomputer.  The  PLURIBUS  system  uses  a novel  control  scheme 
that  permits  elimination  of  processor  specialization  and  produces 
a highly  modular  system.  The  PLURIBUS  does  not  employ  interrupts. 
Instead  it  uses  special  hardware,  called  a PID  or  Psuedo  Interrupt 
Device,  to  Implement  a "task  queue"  for  all  processors.  This 
approach  allows  construction  of  systems  which  degrade  gracefully, 
automatically  trading  performance  for  module  failures  while  con- 
tinuing to  execute  all  application  functions.  PLURIBUS  systems 
are  bus  oriented  and  are  built  up  from  four  basic  types  of  busses: 
Processor  busses.  Memory  busses,  Input-Output  busses,  and 
Memory/Input  Output  busses.  The  initial  configuration  for  the  CCP 
contains  two  Processor  busses  and  two  Memory/Input  Output  busses. 

The  CCP  system  also  contains  a Tektronix  display  and  hard 
copy  printer,  2 Texas  Instruments  Silent  700  terminals,  3 CODEX 
4800  b.p.s.  modems,  and  a REMEX  paper  tape  reader/punch.  The 
PLURIBUS,  tape  reader/punch,  and  modems  are  mounted  in  three  racks. 

The  CCP  contract  was  awarded  in  September  of  1974.  Within  a 
month  of  that  time  most  of  the  hardware  was  on  order.  The  Hardware 
and  Software  Development  Specifications  were  completed  early  in 
November  and  work  was  begun  on  software  implementation.  The 
system  hardware  was  assembled  in  January  1975  and  was  available 
part  time  for  program  checkout  in  February.  The  first  versions  of 
most  of  the  software  modules  were  coded  by  June  1975- 

Meanwhile,  design  and  implementation  of  other  nodes  in  the 
seismic  data  network  were  in  progress.  As  coding  of  software 
for  various  nodes  in  the  network  progressed,  it  became  evident  that 
modifications  to  the  communication  protocols  would  be  necessary. 
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As  these  changes  were  defined  modifications  to  the  CCP  programs  had 
to  be  made. 

Software  checkout  prior  to  CCP  delivery  was  facilitated  by 
temporarily  routing  some  of  the  leased  line  inputs  to  BBN. 

Realistic  system  level  checkout  was  not  practical,  however,  until 
the  equipment  was  delivered  to  SDAC  and  other  nodes  in  the  network 
were  available  for  testing. 

The  equipment  was  shipped  in  July  1975  and  installation  was 
complete  early  in  August.  By  then  it  was  evident  that  the  network 
would  not  be  ready  for  system  level  tests  in  time  for  scheduled 
system  completion,  and  that  further  protocol  and  format  modifications 
would  be  required.  The  contract  was, therefore , extended  to  the 
end  of  calendar  1975. 
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CCP  ACCEPTANCE  TEST 

The  CCP  acceptance  tests  were  started  in  November  of  1975. 

The  delivered  system  included  the  hardware,  the  application  system 
software,  PLURIBUS  "reliability"  system  software,  test  and  diagnostic 
programs,  and  program  support  software.  Acceptance  tests  were 
divided  into  five  phases.  In  the  first  phase,  the  hardware  and 
the  hardware  test  programs  were  demonstrated.  In  the  second  phase 
the  operational  system  was  demonstrated  in  the  full  operational 
configuration.  The  third  phase  demonstrated  the  reliability  software 
that  allows  the  system  to  dynamically  recognize  the  availabl?  working 
system  resources,  to  adapt  the  operation  to  use  these  resources,  and 
to  operate  the  system  in  a divided  configuration  with  part  of  the 
system  hardware  running  test  programs  or  software  development  while 
the  rest  of  the  system  runs  the  operational  system.  Phase  4 consisted 
of  a 24  hour  system  demonstration  in  normal  operating  configuration. 
Phase  5 was  a demonstration  of  the  program  support  software  oper- 
ating on  a TENEX  system. 

The  detailed  acceptance  test  procedures  are  described  in 
BBN  Report  3185  which  is  included  as  Appendix  I of  this  report. 

Since  coordination  was  required  among  many  of  the  operating  sites, 
the  test  procedures  were  not  performed  in  the  order  described  in 
the  test  procedures  document.  Table  1 summarizes  the  dates  on  which 
each  part  of  the  test  was  performed.  As  can  be  seen  from  this 
table,  the  test  period  stretched  out  till  February  of  1976  before 
final  system  acceptance. 

The  acceptance  test  results  Include  the  output  from  the  CCP 
output  terminal,  hard  copy  from  the  CCP  display,  and  computer 
dumps,  listings  and  plots  from  other  sites  sending  and  receiving 
data  directly  to  or  from  the  CCP  or  in  parallel  with  the  CCP. 

These  results  have  been  bound  in  three  volumes  in  order  to  make 
it  easier  to  compare  concurrent  data  from  different  sources. 
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Table 

Acceptance  Test 


date 

day  number 

November  3,4,1975 

307,308 

November  11,  1975 

315 

November  13,  1975 

317 

November  14,  1975 

318 

November  18,  1975  and 

December  12,  1975 
November  25,  1975  and 

322  and 

346 

January  12  , 1976 

329  and 

12 

December  3,  1975, 

337 

December  11,  1975 

345 

December  16,  1975 

350 

December  17,13,1975 

351  and 

352 

January  8,  1976 

8 

December  12,  1975 

336 

January  16,  1976 

16 

January  16,17,  1976 

16  and 

17 

January  16,  1976 

16 

February  4,  1976 

35 

February  5,6,  1976 

36  and 

37 
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Schedule 

Test  Procedure 

1 - System  Testing 

2A  - Operating  the  Display 

2B  - Processing  ALFA  Data 

2D  - Processing  LASA  Data 

2F  - Receiving  KSRS  and 
Site  II  Data 

2E  - Processing  NORSAR  Data 

2G  - Processing  Data  for 
the  VELA  Circuit 

21  - Sending  Data  to  the  DP 

2K  - Check  All  Messages 
Between  CCP  and  DP 

5 - Demonstrate  Editor  and 
Assembler 

2C  - Test  ALPA  Beams 

2L  - Sending  Data  to  the  SIP 

2M  - Check  All  Messages 
Between  the  CCP  and 
the  SIP 

2H  - Changing  and  Interro- 
gating CCP  Status 

2J  - Testing  Changes  in 
Data  Status 

3 - Reliability 

Sample  Event 

4 - System  Operation 
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I 

These  volumes  are  organized  according  to  the  test  procedures 
document  rather  than  chronologic  order  of  test  performance. 

The  following  section  summarizes  the  test  observations. 

I 

PHASE  1.  HARDWARE  SYSTEM  TESTS 

This  phase  was  divided  into  three  parts.  In  the  first 
part  the  hardware  system  test  program,  HIT,  was  demonstrated.  The 
version  demonstrated  was  a later  version  than  that  described  in 
the  original  test  procedures.  The  final  test  procedure  document 
(Appendix  I)  has  been  corrected  for  the  later  version  of  HIT. 

The  second  part  of  this  phase  required  that  known  faulty 
cards  be  inserted  into  the  CCP  and  the  fault  isolated  with  HIT. 

Three  faulty  cards  were  made  available,  an  HLC , a TAG,  and  a 
BCP.  The  HLC  (Host  interface)  card  was  chosen  and  found  using 
HIT.  Next  both  the  bad  HLC  and  the  bad  TAG  (a  memory  card)  were 
inserted.  Again  the  HLC  was  found  but  the  TAG  actually  had  three 
missing  connections  and  the  memory  test  couldn't  isolate  the  problem 
to  the  card,  but  only  to  the  bus.  It  would  have  been  necessary 
to  examine  the  bus  signals  with  a scope  to  isolate  the  problem 
further . 

The  final  step  in  this  phase  was  to  run  HIT  for  2H  hours 
with  no  errors. 

HIT  stores  error  counts  and  indicators  in  designated  memory 
locations  which  must  be  examined  using  the  DDT  program  or  console 
lights.  The  test  results  from  phase  1 are,  therefore,  contained 
entirely  in  the  interactive  teletype  output  (Volume  1 of  test 
results ) . 
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PHASE  2.  OPERATIONAL  PROGRAM  TESTS 

The  various  tests  of  phase  2 check  Individual  data  paths 
and  processing  results  and  then  the  system  as  a whole.  In  order 
to  explain  these  tests,  figures  1 and  2 show  two  basic  network 
configurations  used.  In  configuration  1 (fig.  1),  both  the  "old" 
Detection  Processing  (DP)  system  and  the  "new"  DP  system  are  run 
simultaneously  in  different  360/40  computers  in  order  to  provide  a 
data  path  independent  of  the  CCP  for  comparison.  In  configuration 
2 (fig.  2),  the  second  360/40  is  used  for  the  Event  Processing 
(EP)  system. 

The  tests  in  phase  2 fell  into  three  groups.  The  first 
group  consisted  of  tests  with  individual  sites  on  the  network. 

For  these  tests  the  test  data  consist  of  dumps  and/or  plots  of  the 
data  at  the  site  and  at  the  CCP.  The  sites  tested  individually  in- 
clude ALPA  (test  2B),  LASA  (test  2D),  NORSAR  (test  2E),  KSRS  and 
Site  II  (test  2F) , and  the  VELA  circuit  (test  2G).  The  second 
group  of  tests  consists  of  testing  CCP  internal  processing  includ- 
ing the  CCP  display  (2A),  ALPA  beamforming  (2C),  examination  of 
status  of  both  the  CCP  system  and  the  network  and  control  of  the 
data  flow  through  the  CCP  (2H),  and  smoothing  and  checking  of  data 
status  (2J).  The  test  data  from  these  tests  consist  of  the  inter- 
active teletype  output,  the  output  teletype  output,  and  the  CCP 
display  output . The  third  group  of  tests  combined  testing  of  CCF 
output  to  the  SIP  and  DP  with  overall  system  tests.  These  Include 
tests  21  and  2K  with  the  DP,  and  tests  2L  and  2M  with  the  SIP. 

For  these  tests  an  attempt  was  made  to  collect  data  from  each  node 
from  the  data  source  sites  through  to  the  final  destination  at  the 
SIP  and  DP  with  as  many  data  streams  as  possible  operating  simul- 
taneously. Thus,  the  data  from  these  tests  include  dumps  and  plots 
of  data  at  the  source  sites,  the  CCP,  and  the  SIP  and/or  DP.  In 
addition,  tests  2K  and  2M  involved  testing  the  protocols  for  com- 
munication between  the  CCP  and  the  DP  and  SIP.  Data  from  protocol 
tests  consists  of  dumps  of  messages  and  observations  that  specified 
events  occurred  in  response  to  special  protocol  messages. 
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Testing  with  Individual  Sites 

2B-ALPA 

The  ALPA  site  does  not  have  a convenient  way  of  dumping  data 
at  the  station  for  comparison  with  data  from  the  CCP.  This  test 
was,  therefore,  performed  by  putting  the  system  in  configuration 
1 and  outputting  ALPA  data  from  the  "old"  DP  output  tape  (tape  6) 
as  an  independent  measure  of  the  site  data  for  comparison  with 
data  transmitted  through  the  CCP. 

The  tests  were  performed  during  a period  from  about 
18:30  to  19:30  on  November  11,  1975-  The  test  data  consist  of 
1)  the  CCP  Interactive  TTY  output  including  operator  commands  and 
core  dump  data,  2)  five  plots  from  the  CCP  hard  copy  unit  showing 
ALPA  waveforms,  3)  corresponding  plots  of  ALPA  data  from  the 
"old"  DP  output  tape,  and  4)  a hex  dump  from  the  "new"  DP  output 
tape  of  the  corresponding  ALPA  data. 

2D-LASA 

For  this  test  the  system  was  operated  in  configuration  1. 
There  are  two  data  paths  independent  of  the  CCP,  one  path  is 
the  recordings  made  at  the  site  (tape  1):  and  the  second  uses 
the  360/44  at  SDAC  to  monitor  the  incoming  phone  line  in  parallel 
with  the  CCP  (tape  4).  The  data  format  is  not  compatible  with 
the  "old"  DP  input  from  LASA  so  no  LASA  data  appears  on  tape  6. 

The  tests  were  performed  on  November  13,  1975,  from  about 
19:30  to  21:00.  The  test  data  consist  of  1)  the  output  from  both 
CCP  terminals  including  operator  commands  and  core  dumps,  2) 
eight  plots  of  waveforms  from  the  CCP  hard  copy  output,  3)  plots 
and  tape  dumps  from  the  360/44  tapes,  4)  plots  of  data  from  the 
"new"  DP  system,  and  5)  strip  chart  recordings  and  tape  dumps 
from  tapes  recorded  on  the  PDP-7  computer  at  LASA. 
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During  these  tests  it  was  noted  that  the  plot  scales  avail- 
able on  the  CCP  display  did  not  allow  enough  scales  for  the 
convenient  display  over  the  dynamic  range  of  interest  and  that 
there  were  not  enough  standard  instrument  scales  for  beams, 
subarray  beams,  and  sensors  to  have  independent  high  and  low 
gain  factors. 

In  addition  to  data  messages  it  was  necessary  to  demonstrate 
operator  messages  in  both  directions  and  the  "idle"  messages  sent 
from  the  CCP  to  LASA.  Operator  messages  were  confirmed  by  the 
exchange  of  messages  recorded  on  the  interactive  and  output 
terminals  of  the  CCP.  The  idle  messages  were  confirmed  by  in- 
hibiting them  at  the  CCP  and  observing  that  the  lack  of  these 
messages  was  detected  at  LASA. 

2 E- IVORS  A R 

The  station  tests  with  NORSAR  were  more  complex  than  with 
other  sites  because,  in  addition  to  operator  and  raw  data  messages, 
the  exchange  of  processed  data  had  to  be  tested  and  the  raw  data 
exchange  goes  in  both  directions.  The  raw  data  exchange  was 
tested  in  configuration  1.  The  tests  of  the  processed  data  exchange 
required  that  the  Event  Processing  (EP)  systems  be  running.  These 
tests  used  configuration  2 with  the  second  360/40  at  each  site 
running  EP  systems  instead  of  the  "old"  DP  systems.  Additional 
notes  on  the  test  plans  and  preparation  and  charts  of  the  data 
channels  used  in  the  tests  are  included  in  Volume  2 of  the  test  data. 

Most  of  this  test  sequence  was  successfully  completed  on 
November  18,  1975  (day  332)  from  approximately  17:00  to  19:30. 

During  this  period  it  was  found  that  type  10  messages  were  not 
being  passed  to  the  DP  at  SDAC , and  additional  tests  to  demonstrate 
successful  processing  of  type  10  messages  were  performed  on 
December  2,  1975  (day  346). 
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The  data  from  these  tests  include  1)  both  CCP  teletype 
outputs  including  dumps  of  data  buffers  for  comparison  with 
other  plots  and  listings,  2)  13  waveform  plots  from  the  CCP  hard 
copy  printer,  3)  plots  and  listings  of  data  from  the  "old" 

DP  tape  from  both  NORSAR  and  SDAC  (tapes  3 and  6),  4)  plots 
and  dumps  from  the  "new"  DP  systems  (tapes  2 and  5),  5)  listings 
from  NORSAR  and  SDAC  detection  logs,  6)  listings  of  detection 
logs  received  at  NORSAR  and  SDAC  from  the  other  source,  7)  plots 
from  the  PDP-7  tape  (tape  1)  and  the  360/44  tape  (tape  4). 

A plot  of  NORSAR subarray  beams  from  the  SDAC  output  tape 
which  appears  to  disagree  with  plots  made  at  NORSAR  is  included 
in  volume  3 of  the  test  data.  The  source  of  the  discrepancy 
was  not  identified  so  this  test  of  handling  of  subarray  beams 
was  inconclusive. 

In  addition  to  data  and  processed  data  the  exchange  of 
operator  messages  and  data  requests  were  tested. 

2F-KSRS  and  Site  II 

Since  KSRS  and  Site  II  were  not  operational,  handling  of 
data  from  these  sites  was  tested  using  a simulator  on  the  BBN 
TENEX  system.  The  simulator  transmitted  known  levels  and  saw- 
tooth waveforms  in  the  appropriate  KSRS  format.  The  output  from 
these  tests  consisted  of  1)  outputs  from  both  CCP  terminals 
including  core  dumps  of  data  and  2)  plots  of  waveforms  from  the 
CCP  hard  copy  printer.  These  outputs  were  compared  with  known 
simulated  data. 

These  tests  were  conducted  on  November  14,  1975  (day  318). 
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2G-VELA  Circuits 

Primary  tests  of  the  output  to  the  VELA  circuits  were 
conducted  on  November  25,  1975  from  about  23:00  to  20:00. 

The  test  data  consist  of  1)  the  output  from  both  CCP  terminals 
including  coredumps  of  data  buffers,  2)  five  plots  of  waveforms 
from  the  CCP  hard  copy  printer,  3)  plots,  listings,  and  Heli- 
corder  records  of  data  from  the  VELA  circuits. 

The  test  data  volumes  also  contain  notes  on  the  test 
plans  and  preparations  and  additional  plots  and  listings  from  the 
VELA  circuits,  the  CCP,  and  the  DP  recorded  on  January  12,  1976. 

CCP  Processing  Operations 

In  addition  to  acting  as  a communication  switch  the  CCP 
performs  several  internal  functions  including  displaying 
waveform  and  test  data,  computing  a small  set  of  beams  from  the 
ALPA  data,  monitoring  incoming  data  to  determine  status  of  sensors 
and  communications,  and,  of  course , allowing  the  operator  to 
control  the  data  routing. 

2A-Disp lays 

In  this  test,  the  various  commands  for  selecting  and  modify- 
ing the  data  displayed  on  the  Tektronix  terminals  and  the  output 
typewriter  were  demonstrated.  Test  data  consist  of  the  records 
from  the  two  typewriter  terminals  and  hard  copy  from  the  display. 
It  was  evident  from  these  tests  that  more  flexibility  in  con- 
trolling display  scales  and  a more  convenient  procedure  for 
specifying  the  display  format  would  be  important  for  intended 
CCP  operations. 


The  beamforming  calculations  consist  of  rotating  the  3 
components  of  the  raw  sensor  data,  adding  data  from  all  the 
sensors  of  each  component  with  preselected  delays,  and  performing 
specified  quality  control  functions  including  removal  of  input 
sensor  bias.  The  beamforming  function  was  demonstrated  by  forming 
a selected  set  of,  beams  and  dumping  both  the  beam  outputs  and 
the  input  data.  The  calculations  were  then  checked  by  hand  cal- 
culation of  several  beam  values.  In  addition,  the  beam  outputs 
were  compared  with  beams  formed  using  the  "old"  DP  system.  The 
tests  used  configuration  1. 

These  tests  were  performed  on  December  17,  1975  (day  351) 
approximately  01:30  to  02:15  and  on  December  18,  1975  (day  352) 
from  about  17=30  to  19:00.  The  test  data  include  1)  both  CCP 
terminal  outputs,  2)  7 waveform  plots  from  the  CCP  hard  copy 
device  (one  on  day  351  and  six  from  day  352),  3)  SDAC  develo- 
corder  record,  4)  dump  and  plots  from  the  "new"  DP  output, 

5)  dump  and  plots  from  the  "old"  DP  output,  6)  hand  calculation 
sheets . 

2H-CCP  and  Network  Status 

Commands  for  interrogating  the  status  of  the  CCP  and  the 
other  network  stations  and  for  controlling  the  flow  of  data  through 
the  CCP  were  demonstrated  in  this  test.  Test  output  consists 
of  the  typewriter  records  from  the  CCP.  The  tests  were  conducted 
concurrently  with  test  2J-Sensor  Status  on  January  16,  and  the 
test  data  are  filed  under  test  2J. 

2J -Sensor  Status 

The  smoothing  and  monitoring  of  sensor  and  communciation 
link  status  and  the  generation  and  transmission  of  status  mess- 
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ages  were  demonstrated  in  these  tests.  The  tests  were  conducted 
on  January  16  and  17  (across  the  change  of  day  to  test 
the  automatic  daily  status  message)  of  1976. 

The  test  data  from  this  test  consist  of  1)  output 
from  the  CCP  terminals,  2)  a CCP  hard  copy  plot  and  a dump 
of  the  type  8 message  when  ALPA  data  was  stopped  by  discon- 
necting the  input  (these  are  in  test  data  Volume  3),  and  3) 
a hex  dump  showing  type  7 and  8 messages  transmitted  at  the 
change  of  day. 

Output  and  System  Tests 

These  tests  were  primarily  intended  to  demonstrate  the  out- 
put of  data  from  the  CCP  to  the  SIP  and  DP,  but  they  were  also 
used  as  an  overall  system  demonstration  . For  each  test,  an 
attempt  was  made  to  operate  with  LASA,  ALPA,  and  NORSAR  all  pro- 
viding data  and  to  record  and  compare  data  at  the  source  station, 
at  the  CCP,  at  the  destination,  and  in  some  cases  at  the  "old" 

DP  to  provide  an  alternate  path.  Since  NORSAR,  the  SIP,  and  the 
DP  were  all  essentially  being  checked  out  simultaneously  with  the 
CCP  and  not  in  fully  operational  status,  scheduling  for  these 
tests  was  difficult  and  several  attempts  at  the  tests  had  to  be 
aborted . 

These  tests  are  grouped  with  two  test  sequences  each  for 
the  DP  and  SIP.  The  first  tests  demonstrated  data  exchange 
(type  0 messages)  and  the  second  tests  demonstrated  other  message 
types  required  by  the  communication  protocols. 

21  and  2L-Sending  Data  Messages  to  DP  and  SIP 

For  these  tests  of  the  type  0 (data)  messages,  the  system 

was  in  configuration  1 providing  data  paths  to  "old"  DP  independent 
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of  the  CCP  for  comparison  with  those  going  through  the  CCP. 

Test  21  with  DP  was  conducted  December  3,  1975  (day  337).  The 
data  collected  include  1)  the  CCP  terminal  outputs  including 
data  buffer  core  dumps,  2)  16  waveform  plots  from  the  CCP  hard 
copy  device,  3)  dumps  and  plots  of  data  from  the  "new"  DP  tape 
(tape  5),  4)  dumps  and  plots  of  data  from  the  "old"  DP  tape 
(tape  6),  5)  dumps  of  data  from  NORSAR  DP  (tape  2),  and  6)  dumps 
of  data  from  360/44  tapes  (tape  4). 

Test  2L  was  attempted  on  December  2,  but  some  of  the  data 
from  sites  was  lost.  The  test  was  run  again  on  January  8,  1976. 

The  data  for  this  test  repeats  that  collected  for  test  21  but 
also  includes  dumps  of  data  messages  received  at  the  SIP. 

2K  and  2M -Verif ieation  of  Other  Messages 

For  these  tests  the  system  was  used  in  configuration  2 with  EP 
in  operation.  Type  0 messages  are  data  messages  and  were  checked 
in  the  previous  tests. 

Type  1 (acknowledge  messages)  were  first  tested  by  inserting 
program  patches  to  count  the  number  of  acknowledge  messages  at 
the  sending  and  receiving  locations.  Next  a patch  in  the  sending 
station  caused  acknowledge  messages  to  be  skipped  at  a known 
rate  and  the  effect  on  the  count  at  the  receiver  was  observed. 

Type  4 (host-going-down)  messages  were  tested  by  having  the 
operator  at  the  destination  site  command  his  system  to  send  a 
type  4 message  to  the  CCP.  When  the  message  was  received  at  the 
CCP  a warning  was  typed  to  the  CCP  operator  confirming  the  exchange. 

Type  5 (operator)  messages  were  tested  by  sending  messages 
from  the  CCP  operator  to  each  remote  station  and  requesting  the 
remote  operator  to  send  the  identical  message  back  to  the  CCP 
operator . 
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Type  7 and  8 messages  were  demonstrated  as  part  of  test 
sequences  2J  and  the  test  was  repeated  in  this  sequence. 

The  type  9 (data  filed)  message  is  transmitted  from  the 
SIP  to  the  C CP.  It  was  tested  by  forcing  the  SIP  to  send  such  a 
message  and  observing  that  the  CCP  received  the  message  and 
informed  the  operator. 

Tests  of  the  type  10  and  11  messages  are  included  in  test 
sequence  2E. 

Test  2K  and  2M  were  performed  on  December  11  and  12,  1975 
(days  345  and  346).  In  addition  data  from  December  2 demon- 
strating some  of  these  message  exchanges  is  included  in  the  data 
volumes . 

The  test  data  consist  of  CCP  terminal  outputs  and  dumps  of 
messages  received  by  the  DP  and  SIP. 

PHASE  3:  RELIABILITY  SOFTWARE 

The  tests  in  this  phase  were  designed  to  demonstrate  1)  the 
ability  of  the  CCP  reliability  software  to  recognize  and  recover 
from  various  forms  of  solid  hardware  failures  and  2)  that  the  CCP 
hardware  can  be  split  into  two  logical  machines,  one  running  the 
operational  program  and  the  other  running  system  test  programs. 

For  the  first  tests  in  this  phase,  hardware  failures  were 
caused  by  disconnecting  devices  from  the  fantail  panels  and  by 
turning  off  power  to  various  modules. 

In  the  second  part  of  this  phase  the  HALF  command  which 
causes  the  operational  program  to  use  only  one  processor  bus  and 
one  MI  bus  was  executed,  and  the  busses  not  being  used  by  the 
operational  program  were  loaded  and  run  with  HIT  and  DDT. 

The  last  step  in  this  phase  consisted  of  demonstrating 
the  operator  ability  to  merge  the  interactive  and  output 
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typewriter  functions  onto  either  of  the  two  typewriter  terminals. 
Phase  3 tests  were  conducted  on  January  16,  1976.  The  test  data 
consist  of  the  CCP  terminal  outputs  from  the  tests. 

PHASE  4:  SYSTEM  OPERATION 

This  phase  of  the  acceptance  test  consisted  of  allowing  the 
entire  available  seismic  network  to  operate  with  the  CCP  for  24 
hours  under  normal  operating  conditions.  This  test  was  performed 
on  February  5 and  6 of  1976.  The  data  for  this  test  consist  of 
the  CCP  terminal  outputs.  Starting  at  the  beginning  of  February, 
the  CCP  terminal  outputs  were  collected  and  bound  as  operating 
logs  for  the  CCP.  The  data  from  this  test  are,  therefore,  in 
the  CCP  operating  log. 

PHASE  5:  PROGRAM  SUPPORT  SOFTWARE 

Phase  5 of  the  acceptance  test  demonstrated  the  program 
support  software  Including  the  editor  and  assembler  on  the  TENEX 
system.  The  demonstration  consisted  of  connecting  to  the  131 
TENEX  over  the  ARPANET  from  a terminal  at  SDAC,  using  the  editor 
to  enter  a source  program,  assembling  the  source  program,  and 
using  a special  PLURIBUS  File  Transfer  Protocol  to  send  the  object 
program  to  the  CCP  where  it  was  punched  on  paper  tape  using  the 
CCP  punch.  This  tape  was  then  read  into  the  CCP  and  the  program 
was  run  on  the  CCP. 

The  test  was  performed  on  December  16,  1975-  The  test  data 
consist  of  1)  the  CCP  terminal  outputs  including  results  of 
running  the  assembled  program,  a program  to  compare  a tape  with 
the  contents  of  memory,  on  the  FTP  program  (differences  are 
variables  changed  when  the  in-memory  version  was  run  to  transfer 
the  assembled  compare  program  over  the  ARPANET),  2)  the  paper 
tape,  3)  program  listing  and  4)  the  concordance  from  the  assembly. 
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CONCLUSION 

The  acceptance  test  sequence  ending  on  February  6,  1976 
provided  an  adequate  demonstration  that  the  CCP  hardware  and 
software  met  specifications  and  the  system  was  accepted  by  the 
Air  Force. 

Operation  of  the  system  during  acceptance  tests  and  seismic 
data  network  debugging  revealed  several  refinements  in  the  CCP 
system,  particularly  in  the  operator  interaction,  that 
would  significantly  enhance  the  ease  of  system  operation  and 
the  network  reliability.  These  include  several  changes 
in  the  waveform  display  and  scaling,  the  ability  to  load  the  CCP 
program  from  another  ARPANET  host  and  to  load  CCP  parameters  from 
premade  paper  tape  (to  reduce  keyboard  entry  of  parameters),  and 
a more  robust  network  control  program  (and  possibly  improved  host/ 
host  protocol ) . 
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Communication  and  Control  Processor  Acceptance  Test  Procedure 

The  following  document  defines  a series  of  tests  that 
demonstrate  all  the  currently  useable  features  of  the  CCP . 

The  acceptance  test  procedure  is  divided  into  four 
numbered  phases.  Each  phase  is  divided  into  one  or  more  lettered 
sections.  The  sections  are  designed  to  be  independent  from  one 
another.  Should  the  CCP  be  unable  to  successfully  complete  a 
certain  section  (or  sections) , only  that  section  (or  sections) 
will  be  required  to  be  retested. 

Ideally,  each  input  site  (ALPA,  LASA,  and  NORSAR) 
should  provide  a sine  wave  of  known  amplitude  and  frequency  on 
one  Long  Period  (LP)  and  one  Short  Period  (SP)  channel.  If  that 
is  available,  that  channel  should  always  be  included  among  those 
tested.  If  not  available,  an  otherwise  identifiable  channel 
should  be  chosen. 

A block  diagram  of  the  expected  system  configuration 
during  the  acceptance  test  is  given  in  Figure  1 for  reference 
during  the  tests. 
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PHASE  1 - System  Testing 
1 . A HIT  hardware  test  program 

HIT  is  a general  Pluribus  system  test  configuration 
program  that  can  be  configured  for  many  Pluribus  configurations, 
including  the  CCP.  It  tries  to  test  as  many  of  the  hardware 
features  of  the  machine  as  it  can,  although  not  necessarily  in 
the  exact  same  way  that  an  operational  program  might  use  them. 

All  Processors  run  the  test  simultaneously,  but  asynchronously. 
Since  a test  program  such  as  HIT  must  execute  on  and  use  the 
facilities  of  the  hardware  that  it  is  also  testing,  there  is 
potential  for  confusion.  Thus  the  program  is  written  to  be 
suspicious  of  the  hardware  it  is  executing  on  and  tries  to  rely 
on  as  few  of  the  hardware  features  as  possible  for  its  actual 
execution.  Thus  each  processor  executes  its  tests  quite  indepen- 
dently from  all  others,  all  of  the  code  is  contained  in  each 
processor's  private  memory  (where  it  is  less  vulnerable  to  cor- 
ruption) , the  locking  feature  of  the  bus  couplers  which  provides 
hardware  protection  against  two  or  more  processors  accessing  the 
same  resources  simultaneously  is  not  depended  upon  for  program 
execution,  etc. 


The  program  flow  for  each  processor  is  divided  into  two 
main  parts:  the  memory  test  and  the  Input/Output  (I/O)  test.  For 
the  memory  test,  the  processors  are  assigned  non-overlapping 
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areas  of  the  available  common  memory.  Each  processor  then  tests 
randomly  selected  addresses  with  random  data  within  that  area. 

The  lock  feature  of  the  couplers  is  also  tested.  The  I/O  test 
exercises  the  various  I/O  devices,  such  as  the  Host  interface 
or  checksum-block  transfer  device,  and  the  polling  devices, 
exemplified  by  the  Synchronous  Line  Interface  (SLI).  The 
devices  are  usually  run  crosspatched , although  they  can  also 
be  externally  looped,  run  through  an  echoing  machine,  or  even 
connected  to  each  other.  The  program  sets  up  buffers  of  random 
data  of  random  length  and  sends  this  data  through  each  device. 

When  completed,  the  incoming  data  is  checked  for  consistency  with 
what  went  out  and  all  of  the  values  of  the  status  and  control 
bits  are  checked  for  their  proper  values.  A rudimentary  test  of 
the  Pseudo  Interrupt  Device  (PID)  and  the  Real  Time  Clock  ( RTC) 
also  takes  place  in  the  I/O  test. 

Each  processor  maintains  a list  of  any  errors  it  has 
detected  in  its  local  memory  for  later  inspection  by  the  operator 
The  processors  also  attempt  to  communicate  their  status  through 
a common  memory  communications  area.  If  a console  is  available, 
one  processor  is  designated  to  display  some  of  this  information 
in  the  lights.  This  common  memory  area  is  also  used  for  information 
of  qlobal  interest,  such  as  buffer  pointers  for  devices  (which 
might  be  serviced  by  any  processor.) 
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l.A.l  Load  HIT 

To  run,  the  program  is  loaded  into  one  of  the  processors, 
which  is  also  the  one  which  runs  DDT.  Using  DDT,  or  a patch 
tape,  the  appropriate  configuration  to  be  tested  and  other 
parameters  of  the  test  are  entered.  Using  the  DDT  ~B  and  ~G 
commands,  the  program  is  copied  and  started  in  the  other  pro- 
cessors. A bit  in  the  lower  row  of  console  lights  will  blink 
for  each  processor  which  is  running.  The  corresponding  bit  in 
the  upper  lights  will  blink  when  that  processor  discovers  an 
error.  In  addition,  the  leftmost  bit  of  the  lower  row  will  come 
solidly  on  and  the  next  bit  will  blink  for  any  error  discovered. 
The  details  of  the  errors  can  be  discerned  by  examination  of 
each  processor's  error  buffer.  Details  of  the  error  formats  and 
parameters  are  given  in  the  listing. 

The  following  pre-run  time  modifications  are  necessary 
to  configure  HIT  to  test  the  CCP: 

1.  The  starting  address  of  the  memory  busses  - BGADDR 

1F30/  p 

1F32/  6000 

2.  Number  of  4K  memories  on  each  bus  - N04KS . This  is  normally 
10.,  but  one  memory  on  the  6000  bus  is  used  for  DDT.  The  C000 
bits  mean  don't  do  I/O  from  the  F bus  to  zero  memory. 


5 


Report  No.  3185  Bolt  Beranek  and  Newman  Inc. 

1F34/  C00A 

1F36/  9 

3.  Hosts  to  test  - MD1ADR . 

1F40/  E140 

1F42/  F 1 40 

4.  CBTs  to  test 

1F44/  E 1 20 

1F46/  F120 

5.  SLIs  to  test  - SLIADR. 

1FBE/  E160 

1FC0 / E168 

1FC  2/  E17 p 

1FC4/  E178 

1FC6/  E18(7 

1FC8/  E188 

1FCA/  F160 

1FCC/  F16  8 

1FCE/  F170 

1FD0/  F178 

1FD2/  F18J3 

1FD4/  F 18  8 


5.  Don't  process  remote  power  fail  interrupts  - OPTION. 

1F0A/  20 
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6.  Select  a processor  to  handle  devices  - MODPNO. 

1F1 8/  22 

7.  Select  a DDT  processor  - DDTPNO . 

1F1A/  22 

8.  Split  the  memory  among  the  4 processors  - ANDBTS . 

1F1C/  1F7A 

9.  Set  DDT  start  address  - DDTSA. 

1F1E/  4000 

10.  Choose  a memory  for  DDT  - DDTMAP . 

IF  2/0/72$/) 

HIT  Will  be  started  at  address  7$$ (hex) . The  error  buffer, 
described  on  page  96  of  the  HIT  listing,  resides  in  locations  509 
to  6 20 . 

l.B  Isolate  Faulty  Card 

HIT  will  be  used  as  a diagnostic  tool  to  help  isolate 
faulty  hardware.  To  demonstrate  this  feature,  a BBN  person  will 
supply  a group  of  faulty  cards.  The  test  witness  will  choose  one 
and  the  BBN  person  will  insert  it  into  the  CCP  and  show  how  to 
use  HIT  to  help  locate  it.  The  errors  will  be  identified  using 
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console  lights  and  a printout  of  the  error  list  maintained  in 
the  local  memory  of  the  processor. 

1 . C 24  Hour  Test 

HIT  will  be  run  continuously  for  24  hours  with  all  I/O 
devices  internally  crosspatched . If  errors  occur,  the  test  will 
be  stopped,  causes  of  the  errors  logged  by  printing  out  the 
error  list  in  each  processor,  repairs  made  if  necessary,  and  the 
test  will  be  restarted.  This  phase  of  the  acceptance  test  will 
end  when  24  hours  of  error  free  operation  have  been  logged.  Power 
line  voltage  will  be  monitored.  Should  errors  be  caused  by  power 
line  fluctuation  the  test  will  not  be  stopped.  A power  line 
fluctuation  is  defined  as  the  line  voltage  remaining  below  7J9 
volts  for  one  half  cycle. 
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PHASE  2 - The  Operational  Program 

The  operational  Program  will  be  loaded  into  the  machine. 
All  parameters  in  Appendix  2 should  be  initialized.  Complete 
details  of  all  operator  commands  will  be  found  in  the  user 
manual . 

Section  2. A - Operating  the  display  (using  the  ALPA  data) 


2.A.1  List  the  ALPA  channels. 

If  they  have  not  been  previously  specified,  they  can  be 
with  the  SPECIFY  command: 

SPECIFY  ALP<cr> 

SP:<cr>  /there  are  no  SP  channels  at  ALPA 

LP:  ALPf) lIHxxxxl<cr>  /fill  in  the  12  character  name 


LP:  <cr>  /terminate  the  prompted  input 

An  incorrect  channel  name  will  be  included. 

Now  they  can  be  listed: 
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LIST  ALP<cr>  /list  the  channels  at  ALPA 

The  incorrect  names  will  be  corrected  and  given  a status  by  the 
REPLACE  command: 

REPLACE  <current  ID>  <new  ID>  Coptional  stacusXcr> 

status  values  may  be  N = No  data 

C = Calibration 
E = Communication  error 
S = Suspect 

The  LIST  command  will  be  repeated  to  confirm  the  result  of  the 
REPLACE  command. 

2. A. 2 Display  an  ALPA  channel. 

The  display  command  uses  the  twelve  character  channel 
IDs,  a gain  factor,  and  a position  on  the  screen.  There  are 
eight  possible  positions  on  the  screen,  referred  to  by  the 
numbers  0 through  7. 

DISPLAY  Cchannel  ID>  <screen  position>  <gain><cr> 
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2. A. 3 Change  the  time  base  of  the  displayed  pattern. 

The  default  time  base  is  30  seconds.  Change  it  to  100 
seconds  by: 

DURATION  100<cr> 

2. A. 4 Freeze  the  picture  on  the  screen. 

The  display  will  be  stopped  by: 


HOLD<cr> 

2. A. 5 Print  a copy  of  the  screen. 

A hardcopy  of  the  contents  of  the  screen  will  be 
produced  by  depressing  the  "Make  Copy"  switch  on  the  keyboard 
console  of  the  display  device. 

2. A. 6 Resume  displaying  data. 

Data  will  once  again  be  displayed  (from  the  current 
time  onwards)  by: 

CONTINUE<cr> 


j 
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2. A. 7 Change  the  gain  factor  and  screen  position. 

The  gain  factor  and  screen  position  of  one  channel  will 
be  changed  by  reissuing  the  display  command  with  a different 
argument  in  the  "gain"  position: 

DISPLAY  Cchannel  ID>  <screen  position>  <new  gain><cr> 

Displayed  values  will  be  compared  with  a hex  dump  of  data  from 
magnetic  tape. 

2. A. 8 Terminate  displaying  a channel. 

Channels  will  be  terminated  by  the  use  of  the  END 

command : 

END  <screen  position> 

2. A. 9 Setting  and  Examining  Parameters 

The  gain  factor  of  one  channel  will  be  changed  using 
the  SET  command.  The  change  will  be  verified  using  the  PRINT 
command  and  the  display  of  the  modified  channel. 
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Section  2.B  - Processing  ALPA  data. 

2.B.1  Check  and  set  up  all  the  constants. 

If  the  ALPA  channels  have  not  yet  been  specified,  they 
must  be  done  as  specified  in  section  2. A. 

In  addition,  there  are  many  error  constants  and  error 
limits  for  each  input  site  which  are  described  in  The  User  Manual. 
The  following  ALPA  values  will  be  used  for  the  test  and  may  be 
printed  with  the  PRINT  command. 


HL 

High  Long  Period  Gain 

.288 

LL 

Low  Long  Period  Gain 

1.0 

MC 

Missing  Message  Constant 

.0625 

MG 

Missing  Message  Good  Limit 

. 3 

MB 

Missing  Message  Bad  Limit 

. 7 

CC 

Checksum  Constant 

.0625 

CG 

Checksum  Good  Limit 

. 3 

CB 

Checksum  Bad  Limit 

. 7 
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oc 

Operator  Missing  Message  Constant 

.(*625 

OG 

Operator  Missing  Message  Good  Limit 

.25 

OB 

Operator  Missing  Message  Bad  Limit 

.75 

PC 

Operator  Checksum  Constant 

.0625 

PG 

Operator  Checksum  Good  Limit 

. 25 

PB 

Operator  Checksum  Bad  Limit 

. 75 

NC 

No  Data  Constant 

.0625 

NG 

No  Data  Good  Limit 

.2 

NB 

No  Data  Bad  Limit 

.8 

EC 

Communications  Constant 

.0625 

EG 

Communications  Good  Limit 

.2 

EB 

Communications  Bad  Limit 

.8 

SC 

Suspect  Data  Constant 

.0625 

SG 

Suspect  Data  Good  Limit 

.2 

SB 

Suspect  Data  Bad  Limit 

.8 

In  addition,  there  are  two  others  which  are  not  applicable  to 
ALPA.  They  are: 


I 

1 
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HS  High  Short  Period  Gain 

LS  Low  Short  Period  Gain 

2.B.2  Display  ALPA  data. 

Two  ALPA  channels  including  one  with  a calibration 
signal  will  be  displayed  using  the  procedures  described  in 
Section  2. A. 

2.B.3  Verifying  .ALPA  data. 

Several  randomly  selected  ALPA  channels  will  be 
displayed.  Near  the  end  of  a display  frame  the  CCP  will  be 
stopped.  ALPA  data  messages  will  be  listed  using  DDT  and  a TTY 
for  comparison  with  plots  and  dumps  of  data  being  stored  on  mag 
tape  by  the  Detection  Processor  (DP)  in  parallel  with  CCP 
operations,  and  with  plots  from  the  CCP. 

Section  2.C  - Test  ALPA  Beams. 

As  in  Section  2.B,  the  module  that  creates  ALPA  Beams 
requires  certain  constants  and  limits  included  in  the  set  up 
procedure  in  Appendix  2.  These  include  the  following  beam 
parameters : 
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RC 

Site  error  constant 

.0625 

RG 

Site  error  good  limit 

.2 

RB 

Site  error  bad  limit 

.8 

ST 

# of  bad  sites  per  component  tolerated 
0<=n<=19 

15 

TU 

upper  tolerance  scale  factor 

100 

TL 

lower  tolerance  scale  factor 

.01 

QT 

# bad  channels/component  tolerated 
with  bad  status 

15 

AR 

mean  calculation  (i/c) 

.05 

AD 

mean  calculation  deviation 

20 

QR 

quality  checking  (1/c) 

.125 

BC 

station  error  constant 

. 125 

BG 

station  error  good  limit 

.2 

BB 

station  error  bad  limit 

. 8 

2.C.1  Define  beams 

In  this  step,  4 beams  will  be  defined.  The  beams  will 
include  two  rotated  single  sensors,  one  sensor  beam  using  the 
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sensors  in  the  first  two  beams,  and  a standard  Air  Force  beam 
using  all  sensors.  The  sensors  used  in  the  first  3 beams  will 
contain  normal  seismic  data.  In  the  following  commands,  the 
channel  IDs  are  the  names  of  the  resulting  beams.  These  are  the 
names  which  will  be  supplied  to  DISPLAY  to  show  the  beams  on  the 
display  screen.  Seismometers  can  be  excluded  from  the  beam  by 
giving  a null  delay.  Rotation  of  a single  seismometer  can  be 
done  by  defining  a one  site  beam.  Beams  will  be  created  as 
follows : 

BEAM  1 <cr> 

COMPONENT  VERTICAL:  APP01BHA030Z  <CR> 

COMPONENT  RADIAL:  APP01BHA030R  <CR> 

COMPONENT  TRANSVERSE:  APP01BHA0 30T  <CR> 

ANGLE : 30*  <CR> 

DELAY  1:  <CR>  Note:  This  is  an  example  of  a "null"  delay. 

DELAY  2:  0 <CR>  Note:  This  is  an  example  of  a zero  delay. 

DELAY  3 : <CR> 

II 

II 

II 

DELAY  19:  <CR> 
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BEAM  2 <CR> 

COMPONENT  VERTICAL:  APP01BHB0 30Z  <CR> 

! M 

II 

| ANGLE:  30*  <CR> 

DELAY  1:  9 <CR> 

* DELAY  2:  <CR> 

II 
• I 

DELAY  19:  <CR> 

BEAM  3 <CR> 

COMPONENT  VERTICAL:  APP01BHC03  0Z  <CR> 


II 


ANGLE: 

30 

* <CR> 

DELAY 

1: 

9 <CR> 

DELAY 

2: 

0 <CR> 

DELAY 

II 

3: 

<CR> 

II 

DELAY 

19: 

<CR> 
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BEAM  4 <CR> 

COMPONENT  VERTICAL:  APP01BHD060Z  <CR> 

COMPONENT  RADIAL:  APP01BHD060R  <CR> 

COMPONENT  TRANSVERSE:  APP01BHD060T  <CR> 

ANGLE:  60*  <CR> 


DELAY 

1: 

18 

<CR> 

DELAY 

2: 

23 

<CR> 

DELAY 

3: 

13 

<CR> 

DELAY 

4: 

9 

<CR> 

DELAY 

5: 

5 

<CR> 

DELAY 

6: 

14 

<CR> 

DELAY 

7: 

26 

<CR> 

DELAY 

8: 

15 

<CR> 

DELAY 

9: 

10 

<CR> 

DELAY 

10: 

6 

<CR> 

DELAY 

11: 

7 

<CR> 

DELAY 

12: 

11 

<CR> 

DELAY 

13: 

12 

<CR> 

DELAY 

14: 

17 

<CR> 

DELAY 

15: 

21 

<CR> 

DELAY 

16: 

16 

<CR> 

DELAY 

17: 

21 

<CR> 

DELAY 

18: 

24 

<CR> 

DELAY 

19: 

19 

<CR> 
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2.C.2  Verify  which  beams  are  now  defined. 

This  is  done  by: 

ALPA<cr> 

which  will  list  all  the  currently  defined  beams. 

2.C.3  Start  calculation  of  the  beams. 

To  start  calculation  of  a beams  use  the  commands: 

START  1 <CR> 

START  2 <CR> 

START  3 <CR> 

START  4 <CR> 


2.C.4  Display  beams. 

After  starting  the  beam  computations,  display  the  three 
components  of  beam  4 as  follows: 


DISPLAY 

APP01BHD06OZ 

1 

1 

. 001 

<CR> 

DISPLAY 

APP013HD060R 

2 

3 

. 001 

<CR> 

DISPLAY 

APP01BHD060T 

3 

5 

.001 

<CR> 
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2.C.5  Verify  beam  computation 

After  enough  time  has  elapsed  to  fill  the  screen  with 
beam  data,  stop  the  CCP.  Take  a hard  copy  and  visually  compare 
with  the  corresponding  plots  of  the  existing  Air  Force  beamforming 
programs . Take  dumps  of  the  30  second  ALPA  data  buffer  and  the 
output  buffers  containing  beams  and  perform  the  following  checks: 


Seismometer  rotation  will  be  checked  by  performing  the 
following  hand  calculation  on  three  most  recent  input  data  values 
from  site  2 (3-02)  and  comparing  with  the  components  of  beam  1 
from  the  dump: 

define  S = N-S  input  channel  from  site  2 

E = NE-SW  input  channel  from  site  2 
W = NW-SE  input  channel  from  site  2 
then  the  values  of 

APP01BHA060Z  = . 577 (S+E+W) 

APP01BHA0  60 R = .707  (E-S) 

APP01BHA060T  = . 815  ( . 5S+ . 5E-W) 

Beamforming  will  be  checked  by  performing  the  following 
hand  calculations  on  corresponding  components  of  beams  1 and  2 
and  comparing  with  beam  3: 

2x  beam  3 (T)  = beam  1 (T)  + beam  2 (T+9) . 
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Beamf orming  and  beam  display  will  be  further  checked  by  comparing 
values  of  beam  4 from  the  hex  dump  with  the  displayed  beam  and 
with  an  Air  Force  plot  and  hex  dump  of  the  beam  data  from  the 
"old  DP"  output  tape. 

Finally,  the  command  to  stop  beam  calculation 
STOP  4 <cr> 

will  be  executed  causing  the  data  traces  on  the  display  to  stop. 

2.C.6  Checking  beam  and  quality  checking  parameters. 

2.C.6.A  Site  error  parameters. 

Site  error  parameters  will  be  checked  by  creating  a 
beam  from  just  one  site  which  happens  to  be  good.  Using  the 
REPLACE  command  set  the  status  to  be  bad.  The  beam  will  become 
null  until  the  time  constant  causes  the  channel  to  be  declared 
good  again.  A second  beam  using  this  site  and  a site  declared 
bad  at  the  ALPA  station  will  be  formed  and  the  two  beams  compared 
to  show  that  the  bad  site  is  not  being  used  in  beamforming. 

2.C.6.B  Check  mean  and  quality  calculations. 

For  the  following  tests,  one  ALFA  site  will  provide  a 
sequence  of  three  test  signals  for  approximately  1(7  minutes  each. 
The  test  signal  consist  of  a 25  ;im.  step  function  lasting  at 
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least  3 minutes,  a 2um.  square  wave  with  a period  between  30  and 
60  seconds,  and  a 5?  nm.  square  wave  with  a period  between  30 
and  69  seconds. 


I 

I 

I 

I 

I 

I 

I 

I 

I 

I 

i 

I 


Two  normal  operating  sites  will  be  selected.  A beam 
containing  the  two  normal  sites  and  the  test  site  all  with  zero 
delay  and  a beam  conditioning  only  the  test  site  will  be  formed. 

The  test  site  channels  and  the  beam  channels  will  be 

displayed. 


The  time  constant  for  the  calculation  of  the  mean  bias 
will  be  checked  by  observing  the  decay  of  the  step  function. 

The  time  constant  for  computing  the  power  average  will 
be  checked  by  observing  the  time  period  between  the  start  of 
small  square  wave  and  the  appearance  of  the  square  wave  on  the 
three  site  beam  which  is  delayed  until  the  average  power  of  the 
square  wave  enters  the  power  gate  controlled  by  the  normal 
seismometers.  Further  checks  will  be  made  by  typing  the  average 
power  of  the  test  site  beam  on  the  operator  console  several  times 
during  the  rise  of  the  step  function  and  the  large  square  wave. 


i- 
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2.D.1  LASA  Constants 

The  constants  will  have  been  set-up  during  initialization 
The  values  will  be  verified  with  the  print  command. 

2.D.2  Display  LASA  data. 

Pour  channels  will  be  displayed  using  the  procedures 
described  in  section  2. A.  If  available,  the  one  calibration  sine 
wave  will  be  included  among  the  channels  displayed  as  a check  on 
data  quality.  Other  channels  will  be  one  LP  channel,  one  SP 
sensor  channel  and  one  SP  beam.  Data  will  be  compared  with  a 
hex  dump  at  selected  points. 

2.D.3  Send  an  operator  message  to  LASA 

Messages  may  be  send  to  sites  such  as  LASA,  equipped 
to  receive  operator  messages  by  the  use  of  the  TELL  command: 
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TELL  LAO<cr> 

-<text  of  message><cr> 

-<another  line  of  text><cr> 

-<cr> 

Messages  received  from  sites  such  as  LASA  are  printed 
automatically  on  the  system  status  typewriter  (TTY  2) . A message 
will  be  sent  from  LASA  and  will  be  typed  in  the  form: 

L:<text  of  message> 

2.D.4  Verifying  LASA  data. 

Several  randomly  selected  LASA  data  messages  will  be 
listed  using  DDT  and  a TTY  for  a hexadecimal  dump  comparison 
with  LASA  data  being  stored  on  mag  tape  in  parallel  with  CCP 
operation.  It  will  be  necessary  to  halt  the  CCP  program  to 
obtain  this  data. 

2.D.5  Verify  idle  messages  from  CCP  to  LASA 

Once  each  second  the  CCP  sends  a pseudo  operator 
message  to  LASA.  This  will  be  verified  by  unplugging  the  LASA 
output  line  from  the  fantail  panel.  LASA  operator  will  verify 
that  messages  stop  and  resume  when  cable  is  unplugged  and  then 
replaced. 
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Section  2.E  - Processing  NORSAR  data 
2.E.1  Specify  the  sites. 

NORSAR  and  LASA  and/or  ALPA  site  channels  will  be 
SPECIFIED  and  the  error  constants  and  limits  SET  during 
initiation  (appendix  2) . LASA  and  ALPA  are  sources  of  data  to 
be  sent  to  NORSAR. 

2.E.2  Receiving  NORSAR  Data. 

2.E.2.A  Verify  and  display  received  NORSAR  sensor  data 

Run  both  old  and  new  DP  systems  at  NORSAR  and  SDAC  to 
provide  independent  data  path. 

Set  up  CCP  display  to  display  NORSAR  data. 

After  this  configuration  has  been  running  for  several 
minutes  stop  CCP  near  the  end  of  a display  frame.  Collect  and 
compare  plots  and  dumps  or  listings  of  the  same  data  recorded 
by  old  and  new  NORSAR  DP  old  and  new  SDAC  DP,  and  CCP  plots 
and  core  dumps. 
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2.E.2.B  Verify  received  detection  log  and  EP  results. 

Run  NORSAR  in  new  mode  with  both  DP  and  EP. 

After  system  has  been  running  for  several  minutes  (long 
enough  to  get  some  EP  output)  recording  on  tape  at  NORSAR  and 
SDAC,  collect  and  compare  NORSAR  detection  log  and  EP  results 
recorded  at  NORSAR  and  SDAC. 

2.E.2.C  Test  Operator  messager  from  NORSAR 

Operating  in  new  DP  mode,  NORSAR  operator  will  send  a 
message  to  CCP  operator. 

2.E.3  Sending  data  to  NORSAR 

2.E.3.A  Sending  LASA  and  ALPA  data  to  NORSAR 

Operate  NORSAR  and  SDAC  with  both  old  and  new  DP  systems 
running  and  recording  data  to  provide  independent  data  paths. 

Display  selected  LASA  and  ALPA  channels  on  CCP  display. 

After  the  system  has  been  running  for  several  minutes, 
stop  the  CCP  near  the  end  of  a display  frame.  Collect  and 
compare  plots  and  listings  or  dumps  of  selected  LASA  and  ALPA 
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data  from  1)  PDP-7  recordings  at  LASA  2)  old  DP  at  SDAC, 

3)  new  DP  at  SDAC,  4)  CCP,  5)  NORSAR  DP. 

2.E.3.B  Sending  data  requests  and  processed  data  to  NORSAR 

Operate  SDAC  and  NORSAR  in  new  mode  with  EP  operating. 

Initiate  a request  for  selected  NORSAR  SP  data  and 
display  NORSAR  SP  data  at  CCP.  Verify  that  the  requested  data 
is  being  received  and  displayed.  Collect  and  compare  dumps  or 
listings  of  SDAC  detection  log  at  SDAC  and  at  NORSAR. 

2.E.3.C  Test  operator  messages  to  NORSAR 

Operating  in  new  mode,  CCP  operator  will  TELL  NORSAR  a 
message.  NORSAR  operator  will  verify  receipt  of  the  message. 


Section  2.F  - Receiving  KSRS  and  Site  II  data. 

2.F.1  Prepare  to  use  simulator. 

The  KSRS  simulator  runs  on  the  BBN-TENEXA  system  in 
Cambridge,  Massachusetts.  Unfortunately,  the  TENEX  clock  is 
running  on  Eastern  Standard  Time  (EST)  plus  or  minus  about  1 min.. 
Therefore  the  CCP  clock  must  be  set  to  that  time  in  order  to 
receive  data.  This  will  require  halting  the  CCP  program  to 
determine  the  exact  time  difference. 
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2.F.2  Specify  the  KSRS  site. 

The  simulator  has  10  short  period  channels  and  20'  long 
period  channels.  Channel  specification  is  part  of  initiation 
procedure  (Appendix  2) . 


2.F.3  Set  up  the  error  rates. 

Initialization  wili  have  been  done  as  in  Appendix  2, 
although  it  should  be  noted  that  the  simulated  data  does  not  have 
a valid  checksum  on  any  of  its  messages.  Also,  the  simulator 
provides  only  data  messages. 

2.F.4  Display  a channel. 

This  will  be  done  as  in  section  2. A.  The  simulated 
LP  channels  are  continuous  levels  of  several  different  gains, 
and  the  SP  channels  are  saw  tooth  waveforms.  Parameters  of  these 
signals  are  as  follows: 

LP  Channel  # value  of  each  sample 

1 0 

2 1 

• • 

• • 

20  19 
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SP  Channel  # 

1 
2 

IV 

Stop  CCP  and  collect  core  dump  to  compare  with  simulator  levels. 
2.F.5  Site  II 

Change  host  ID  of  simulator  and  repeat  2.F.4. 

Section  2.G  - Processing  data  for  the  VELA  circuit. 

This  section  will  be  tested  using  the  full  duplex 
telephone  circuits  provided  for  VELA  3.  Data  will  be  verified 
by  hexadecimal  dumps  at  both  ends. 

2.G.1  Sending  data  on  the  VELA  3 line. 

Data  will  be  send  on  the  VELA  3 line  from  any  of  the 
following  sources  available  to  the  CCP:  ALPA,  ALPA  beams,  LASA, 
and  NORSAR.  The  choice  of  sites  and  channels  is  made  using  the 
SEND  command: 


the  20'  values  per  second 

0,  10'  20,  ...190 

1,  11,  21,  ...191 

9,  19,  29,  ...199 
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SEND<cr> 

SHORT  PERIOD  CHANNELS 
HOST:  <site  IDXcr> 

ALL  CHANNELS?  <yes><cr>  /yes  sends  all  SP  channels  from  chosen 

site 

HOST:  <site  IDXcr> 

ALL  CHANNELS?  <noXcr> 

CHANNEL:  <channel  IDXcr> 

CHANNEL:  <cr> 

LONG  PERIOD  CHANNELS 
HOST:  <site  ID>  <cr> 

(same  as  SP  channels) 

HOST:  <cr> 

In  order  to  easily  verify  data  quality,  at  least  one  calibration 
sine  wave  should  be  included  among  the  channels  sent.  Block 
waveform  data  will  not  be  sent.  Selected  data  will  be  displayed 
at  the  CCP.  After  several  minutes  of  operation,  the  CCP  will  be 
halted  and  dumps  of  recent  output  data  will  be  recorded.  Dumps 
and  plots  of  data  from  the  CCP  will  be  compared  with  dumps  and 
plots  of  data  from  the  VELALINK.  Note  that  beam  data  on  the 
VELALINK  is  delayed  25  seconds  and  sensor  data  is  delayed  10 


I 

I 

I 


seconds . 
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2.G.2  Receiving  operator  messages  from  VELA. 

Operator  messages  will  be  received  from  VELA  via  the 
reverse  link  of  one  of  the  VELA  lines.  A message  addressed  to 
the  CCP  operator  will  be  received  and  will  be  automatically 
printed  on  the  status  TTY  (TTY  2) . They  have  the  form: 


HC:  <text> 

2.G.3  Checking  Codex  Modems 

Correct  modem  operation  will  be  demonstrated  by 
switching  to  each  of  the  three  modems  for  VELA  communication. 

One  of  the  modems  will  be  located  at  the  highest  of  the  4 spaces 
to  demonstrate  that  the  cables  will  reach  all  modems. 

Section  2.H  - Changing  and  Interrogating  CCP  status. 

2.H.1  Print  and  set  host  IDs. 

The  ARPANET  address  of  a host  will  set  with  command, 
for  example: 

SET  NH  41<cr> 

will  set  the  address  of  NORSAR  to  be  41.  Verify  this  by: 
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PRINT  NH<cr> 

which  will  print  the  current  host  address  for  NORSAR.  The  other 
host  IDs  and  addresses  (where  known)  are: 


NH 

NORSAR 

41. 

KH 

KSRS 

? 

IH 

ILPA 

7 

2H 

SITE  2 

7 

4A 

36J3/4j3A  DP 

167. 

SH 

SIP 

223. 

4H 

360/44 

295. 

i 

| 

I 

If  data  normally  sent  to  the  40A  were  to  be  sent  to  the  40B 
instead,  then  the  ARPANET  address  of  the  40B  would  be  associated 
with  4A  using  the  set  command. 

2.H.2  The  STATUS  and  PREFER  commands. 

The 

STATUS<cr> 

command  causes  a printout  on  the  status  TTY  of: 

1.  Input  site  status  table 
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2.  ARPANET  host  table 

3.  CCP  device  table 

4 . CCP  map  table 

5.  CCP  illegal  instruction  trap  table. 

This  same  list  is  also  periodically  printed  by  the  system  to 
provide  a permanent  record  of  system  behavior.  All  devices  in 
this  list  are  given  a two  letter  identifier  (see  CCP  User 
manual  for  device  identifier  list) . 

A different  interface  or  no  interface  may  be  selected 
by  the  operator  by  use  of  the  PREFER  command.  For  example: 

PREFER  AL  0 :cr> 

will  cause  the  system  not  to  receive  ALPA  data.  Whenever  the 
system  decides  to  change  the  device  it  is  using,  it  will  so 
inform  the  operator  on  TTY  2 and  it  will  sound  the  audible 
signal.  The  use  of  this  command  will  cause  the  system  to 
confirm  the  new  choice.  Each  device  has  two  possible  interfaces 
that  may  be  used.  In  each  case  the  system  will  try  to 
automatically  choose  the  interface  that  is  actually  connected  to 
the  device.  In  the  case  of  a modem  the  system  will  look  for 
carrier.  In  the  case  of  the  IMP,  the  system  will  look  for  IMP 
READY.  In  each  case,  the  CCP,  unless  told  to  use  no  device,  will 


A 
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choose  the  one  that  is  active.  Therefore,  if  the  ALPA  modem  is 
connected  to  the  E160  interface  and  the  operator  PREFERS  the  F160 
interface,  the  system  will  NOT  switch  over,  unless  the  F160 
interface  is  active.  This  will  be  verified  by  displaying  ALPA 
data,  PREFERing  AL  to  0,  seeing  the  data  stop,  PREFERing  AL  to 
the  active  interface,  and  seeing  the  data  reappear. 

2.H.3  The  OUTPUT  command. 

The  OUTPUT  command  permits  the  operator  to  divert  the 
data  stream  normally  sent  to  the  status  TTY  to  either  of  the  TTYs 
or  to  the  display.  The  command  is: 

OUTPUT  <1,2,  or  DIXcr> 

where  the  choices  are: 

1 The  normal  interactive  TTY 

2 the  normal  status  TTY 

DI  The  display 

The  series  of  commands  to  demonstrate  this  command  and  its 
interaction  with  the  display  will  be: 

HOLD  to  stop  the  current  display 

OUTPUT  DI  to  divert  status  to  the  display 
STATUS  list  system  devices  and  status 
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OUTPUT  2 resume  using  the  status  TTY 
CONTINUE  continue  graphics  display 

Section  2.1  - Sending  data  to  the  4pA  (DP) 

The  4j2A  always  receives  NORSAR  offline  results.  In 
addition,  data  from  any  of  the  sites  may  be  sent  to  the  4j3A  by 
use  of  the  SAVE  command. 

2.1.1  Send  data  to  the  4J8A. 

Sending  data  to  the  4pA  will  be  set  up  with  the  SAVE 

command : 

SAVE  40A<cr> 

SP:  <site  name><cr> 

SP:  <cr> 

LP:  <site  name><cr> 

LP:  <cr> 

*r 
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In  order  to  provide  automatic  backup,  in  the  event  that  the  SIP 
is  down,  all  data  specified  to  be  sent  to  the  SIP  is,  instead, 
sent  to  the  40A  in  addition  to  NORSAR  offline  data,  and  the  40A 
SAVE  specification  is  ignored.  Therefore,  to  restrict  the  data, 
for  example  to  send  just  the  ALPA  data  to  the  40A,  with  no  SIP, 
the  SAVE  command  will  be  given: 

SAVE  SIP<cr> 

SP:  <cr> 

LP:  ALP<cr> 

LP : <cr> 

The  switch  from  SIP  to  40A  SAVE  specification  may  be  forced  by 
use  of  the  SIP  DOWN  command.  The  inverse  may  be  performed  with 
the  SIP  UP  command. 

In  order  to  provide  an  independent  data  path  for 
comparison  the  "old"  Detection  Processing  (DP)  system  will  be 
run  in  the  other  360/4 0.  The  CCP  display  will  be  set  up  showing 
one  or  more  waveforms  from  each  source  site  being  used  in  the 
test . 
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After  running  for  several  minutes,  halt  the  CCP  and 
dump  the  output  buffers.  Dumps  or  listings  and  plots  of  selected 
sections  of  waveforms  will  be  collected  from  the  source  site,  from 
the  CCP,  from  the  "new  DP"  system,  and  from  the  "old  DP"  system 
and  will  be  compared  to  confirm  correct  system  operation. 

2.1.2  Switch  output  to  the  40B 

Use  the  SET  command  to  associate  the  40B  ARPANET  address 
with  host  ID  4A. 

2.1.3  Get  requested  data  from  NORSAR. 

NORSAR  sends  off-line  processed  data  to  the  CCP  which 
is  then  forwarded  to  the  40A.  The  CCP  or  DP  operator  will  request 
specific  data  by  use  of  the  REQUEST  command: 

REQUEST  <cr> 

- <#  of  SP  channels,  0-3><cr> 

- <#  of  subarray/array  beam  values,  0-3><cr> 

- <lst  beam  number,  0-999><cr> 

- <2nd  beam  number,  0'-999><cr> 

- <3rd  beam  number,  0-999><cr> 
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NORSAR  data,  CCP  data,  and  40A  data  will  be  compared  by  dumps 
from  each  machine. 

2.1.4  Testing  network  retransmission  and  acknowledges 

If  the  40A  can  so  arrange,  it  will  suppress  the  ACK 
from  every  2(7 th  message.  A retransmission  counter  will  be  kept 
in  the  CCP.  After  a known  period  of  operation  in  this  mode  the 
CCP  retransmit  counter  will  be  printed  and  compared  with  the 
value  determined  from  the  operating  time.  Both  machines  will  be 
stopped  and  acknowledge  messages  will  be  checked  with  hex  dumps. 

2 . J Testing  Changes  in  Data  Status 

2.J.1  The  LIST  command  will  show  the  current  status  of  a channel. 
LIST  ALP  <cr> 

ALP01 IH03231  <STATUS> 


. status  may  be  blank  (good  data)  or  a sequence 
possible  characters  representing  current  status  (more 
may  be  present) . Possible  status  characters  are 


N 

C 


no  data 
calibration 


of  four 
than  one 
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E communication  error 

S suspect  data 

2.J.2  A data  source  will  be  made  to  fail  by  pulling  a modem  plug. 

The  ALPA  fantail  plug  is  removed,  and  the  system  will  inform  the 
operator  of  this  change  on  TTY  2 and  will  sound  the  corresponding 

1 

audible  alert.  A status  message  will  be  sent  to  the  40A 
(assuming  the  SIP  is  down) . The  status  will  be  checked  with  a 
hex  dump  from  the  40A. 

2.J.3.  If  the  project  officer  can  provide  a mechanism  for 
selectively  breaking  the  checksum  (or  polycode)  on  a given  stream 
of  messages,  then  the  error  rate  will  be  moved  around  so  that  the 
LIST  command  will  report  that  the  channels  are  either  good, 
suspect,  or  bad. 

2.K.  Check  all  Messages  Between  CCP  and  40A 

The  NORSAR  Processed  Data  Messages,  Seismic  Data 
Messages,  Acknowledge  Messages,  and  Status  Message  have  been 
checked  with  various  steps  above. 
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Action  to  cause  the  4J7A  to  send  a Host-Going-Down 
message  will  be  taken.  The  message  will  cause  a CCP  operator 
message  on  TTY  2 with  an  audible  signal.  Message  will  be 
checked  by  stopping  the  CCP  and  taking  a hex  dump.  The  latest 
Processed  Data  to  NORSAR  message  will  also  be  checked  by  this 
hex  dump  and  a dump  from  the  4.0A. 

The  CCP  operator  will  cause  a Structure  Check  Message 
to  be  sent.  Hex  dumps  from  the  40A  and  CCP  will  be  used  to  check 
the  resulting  message. 

2.L  Sending  Data  to  the  SIP 

The  format  of  data  messages  to  the  SIP  is  the  same  as 
to  the  4/5 A.  To  demonstrate  this  capability,  the  procedure 
described  in  section  2.1.1  will  be  repeated  with  the  SIP  on  and 
data  "SAVE"  to  the  SIP.  Data  will  be  dumped  from  the  SIP  and  the 
CCP  for  comparison. 

2.M  Check  All  Messages  Between  CCP  and  SIP. 

Type  0 (data)  messages  have  been  checked  by  the 
procedure  in  2.L. 


Report  No.  3185 


Bolt  Beranek  and  Newman  Inc. 


Type  1 (acknowledge)  messages  will  be  checked  by  having 
the  CCP  and  SIP  keep  counts  of  messages  sent  and  acknowledges 
received.  After  a period  of  operation  stop  and  read  the  counts. 

A program  change  will  then  be  made  to  suppress  every  n'th 
acknowledge  and  the  system  will  be  run  in  this  mode  for  several 
minutes.  The  counts  will  be  examined. 

In  order  to  demonstrate  checksum  computation  the  CCP 
will  be  stopped  and  a dump  of  some  message  will  be  taken.  The 
checksum  will  be  computed  by  hand  and  checked  with  the  checksum 
in  the  dump. 

Type  4 (Host-going-down)  messages  will  be  checked  by 
having  the  SIP  operator  send  a type  4 message  to  the  CCP  and 
observing  the  resulting  CCP  operator  message  on  the  TTY. 

Type  5 (operator)  messages  will  be  checked  by  having 
the  CCP  operator  send  a message  to  the  SIP  operator  and  then 
having  the  SIP  operator  return  the  identical  message  to  the 
CCP  operator. 

Type  7 and  8 (Structure  Check  and  Status)  messages 
will  be  checked  by  forcing  the  CCP  to  send  those  messages  to  the 
SIP  by  turning  backup  on  and  off.  The  CCP  and  SIP  will  then  be 
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stopped  and  dumps  of  these  messages  taken  at  both  sites  and 
compared . 

The  type  9 (Data  Filed)  message  will  be  tested  by 
observing  the  CCP  operator  message  on  the  TTY  after  the  SIP  has 
sent  the  message  at  a prescribed  time. 


Ma 
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PHASE  3 - Reliability 

The  CCP  is  designed  with  duplicate  hardware  so  that  no 
single  failure  will  make  the  machine  inoperable.  However,  since 
devices  are  connected  to  one  interface  at  a time,  they  must  be 
reconnected  to  the  second  interface  in  the  event  of  an  interface 
failure.  Operator  interaction  is  provided  to  assist  in  the 
choice  of  interfaces. 

Memory  and  interface  failure  will  be  simulated  without 
damaging  the  physical  cards  by  shutting  down  the  power  on  the  bus 
into  which  they  are  connected.  The  CCP  has,  in  essence,  three 
different  types  of  busses. 

In  order  to  verify  that  the  CCP  continues  to  operate, 
set  it  up  to  be  receiving  ALPA  data  and  displaying  a channel. 


Section  3. A - Simulate  an  interface  failure. 

Simulate  an  interface  failure  by  pulling  out  the  ALPA 
fantail  plug  and  replugging  it  into  the  other  bus.  The  operator 
will  be  informed  of  the  new  choice  of  devices  by  a message  of  the 
following  form  and  an  audible  alarm  both  on  TTY  2.  Data  will 
resume  being  displayed. 
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Section  3.B  - Simulate  a processor  failure. 

Power  down  the  #12  processor  bus  (the  one  without  the 
console  and  the  display) . After  the  system  has  stabilized  and 
resumed  operations,  power  the  bus  back  up  and  wait  for  the  system 
to  restabilize. 

Section  3.C  - Simulate  a memory  failure. 

Power  down  the  F memory  bus  (center  rack) . After  the 
system  has  stabilized  and  resumed  operations,  power  the  bus 
back  up  and  wait  for  the  system  to  stabilize. 

Section  3.D  - Simulate  a processor  bus  failure. 

Power  down  the  #22  processor  bus.  Since  both  the 
console  and  the  display  are  on  this  bus,  they  will  not  be 
available  for  system  operation  verification.  Instead,  exercise 
some  of  the  functions  described  in  Phase  2 section  H.  Power  the 
bus  back  up  and  wait  for  the  system  to  stabilize. 

Section  3.E  - Operate  the  machine  while  running  the  operational 
and  test  programs. 

Since  the  CCP  contains  enough  equipment  redundancy  to 
make  two  separate  computes  with  memories,  it  is  possible  to  split 
the  system  and  continue  running  the  operational  program  in  one 
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half  while  using  HIT  diagnostics  on  the  other.  This  capability 
will  be  demonstrated  by  the  following  tests. 


3.E.1  Split  the  machine  into  two  halves  by  using  the  HALF 
command: 


HALF  Cnumeric  code  = 8C94 (HEX) ><cr> 

this  particular  code  will  cause  the  system  to  stop  using  the  #12 
processor  bus  and  the  F memory  bus. 

3.E.2  Now  read  a DDT  into  the  unused  memory  bus. 

First  choose  a memory  to  use,  say  the  7200  page: 

SET  PM  29184<cr>  = decimal  equivalent  of  7200  hex 


now  put  the  DDT, 16272  tape  in  the  reader  and  give  the  read 
command : 

PTR<cr> 
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3.E.3  Now  read  in  the  HIT  test  program  and  the  patch  tape  that 
configures  it  as  to  which  processor  and  memory  to  use.  First  set 
up  which  processor  to  load  and  which  I/O  bus  to  use  to  load  it 
(this  process  is  done  via  Backwards  Bus  Coupling) . Since  the 
system  still  controls  the  E bus,  we  should  use  that  one,  and  we 
want  to  load  processor  12.  The  global  variable  "pp"  is  set  to 
the  sum  of  the  bus  address  (hex  F000)  and  the  processor  number 
(hex  12)  : 

SET  PP  - 4078<cr>  = decimal  equivalent  of  F012  hex 

Now  put  the  HIT, 176  tape  in  the  reader  and  issue  the  read  command: 

PTR<cr> 

F 

and  the  patch  tape,  in  this  case  HIT, 176  patch  12F  (busses  12  and 
F)  : 

PTR<cr> 
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d 


Then  using  CCP  DDT: 

DDT  1 on  <cr> 

12:  AH 

F8/7200<cr> 

FC00/1200<cr> 

4000  AG 

3.E.4  At  this  point,  the  diagnostic  DDT  should  be  running  on 
the  F bus  TTY  and  the  test  program  can  be  run  as  discussed  in 
Phas  1. 

To  start  HIT:  Using  Diagnostic  DDT  type: 

AH  100  AG 

Now  copy  HIT  into  other  processor  memory: 

: 10, 1FFEAB  700AG 

To  stop  HIT  type: 

-:  1F04/Kcr> 
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3.E.5  Before  returning  the  12  and  F busses  to  the  system,  halt 
the  HIT  test  program  as  described  in  the  HIT  documentation. 

3.E.6  To  reintegrate  the  system,  once  again  use  the  HALF  command: 

HALF  Cl4<cr> 

The  system  will  now  gradually  absorb  the  new  components. 

3 - F Demonstrate  System  Operation  Using  Only  One  TTY 
Disconnect  TTY  1 then  enter  the  command 
PREFER  T1  0 on  TTY2 . 

Next  execute  any  command  invoking  prompts  from  the  computer  and 
any  of  the  tests  in  the  above  procedures  that  cause  an  output 
message  and  observe  that  all  of  these  operations  and  messages  use 
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PHASE  4 - System  operation 

The  operational  system  will  be  run  for  24  hours  under 
normal  operating  conditions. 
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PHASE  5 - Demonstrate  Editor  and  Assembler. 

Enter  and  assemble  a program  using  the  TENEX  editor 
and  assembler  for  the  CCP.  Punch  the  resulting  tape  and  read 
it  into  the  CCP. 
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APPENDIX  1 - Messages  Typed  By  The  CCP 
<site  name>  MISCNT  BAD 

The  rate  of  missing  messages  for  this  site  has  exceeded  the 
BAD  limit. 

<site  name>  MISCNT  GOOD 

The  rate  of  missing  messages  for  this  site  has  decreased 
below  the  GOOD  limit. 

<site  name>  CHKCNT  BAD 

The  rate  of  checksum  errors  for  this  site  has  exceeded  the 
BAD  limit. 

<site  name>  CHKCNT  GOOD 

The  rate  of  checksum  errors  for  this  site  has  decreased 
below  the  GOOD  limit. 

USING  <device  name>  <device  address> 

Now  using  the  device  given  by  the  device  address  for  the 
CCP  system  component  given  by  the  device  name. 

HOST  DEAD:  <integer> 
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The  Host  with  host  identifier  specified  by  the  integer 
is  not  accepting  data  from  ARPA  network. 

<time>  HOST  GOING  DOWN  <integer> 

The  host  with  host  identifier  specified  by  the  integer  had 
declared  that  it  is  going  down. 

<time>  TBM  ACKNOWLEDGE  < site  name>  <file  name>  <beginning 
time>  <end  time> 

The  SIP  acknowledges  successful  transmission  of  data  to  its 
disk. 
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APPENDIX  2 - Setting  CCP  Paramaters 


1.  Naming  channels  at  a site. 

All  sites  should  have  their  long  and  short  period 
channels  identified.  Refer  to  the  following  section  in  the 
CCP  User  Manual:  section  9.0  Channel  Naming  Commands. 

2.  Each  site  requires  certain  parameters  and  constants  that 
specify  and  describe  the  data.  For  a compilation  of  these 
parameters  refer  to  the  CCP  User  Manual,  Appendix  C. 
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APPENDIX  3 - Acronyms 

CCP  Communicate  and  Control  Processor 

LP  Long  Period 

SP  Short  Period 

I/O  Input/Output 

DMA  Direct  Memory  Access 

SLI  Synchronous  Line  Interface 

PID  Pseudo  Interrupt  Device 

RTC  Real  Time  Clock 

DP  Detection  Processor 

DDT  Dynamic  Debug  Technique 

SIP  Seismic  Input  Processor 

TBM  Tera-Bit  Memory 

ALPA  Alaskan  Long  Period  Array 

LASA  Large  Aperture  Seismic  Array 

KSRS  Korean  Seismic  Research  Station 

ILPA  Iranian  Long  Period  Array 

NORSAR  Norwegian  Seismic  Array 
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